Defining a custom super procedure for an object
The super procedure mechanism has been used to provide SmartObjects™ with their standard behavior for the ADM, and this has been extended with Progress Dynamics. One extension is to provide a field in each SmartObject definition where the developer can define a custom super procedure for it. These are called custom super procedures precisely because the intention is to provide an individual application object with customized behavior not inherited from its standard super procedures and from other code in the framework. So as opposed to the model summarized in the previous section, where a single super procedure can provide common code to support many base procedures, the typical use of a custom super procedure in a Progress Dynamics application is likely to be to provide specific code needed by a single client-side viewer, browser, or other object.
To be sure, this is not always the case. A custom super procedure can provide common support for any collection of other objects, for example, if they have fields in common or special field types and event handling needs in common. But if you find yourself attaching the same custom super procedure to a large number of application objects, you can add that behavior to all the objects as a class customization rather than to the individual objects.
If you want to add behavior to all objects of an existing type in your application, such as all viewers or all browsers, then you can define a super procedure in the adm2/custom directory to extend the class’s behavior by adding another super procedure to every object of the type. This is the same method of class extension available to non-Dynamics adm2 applications. See OpenEdge Development: AppBuilder for more information.
On the other hand, if some group of objects needs the behavior but others do not, then you can use the Class Maintenance tool to define a subclass, so you have two distinct types of objects: one with the behavior and one without. See Chapter 2, "Customizing Classes," for more information about different techniques for extending the object hierarchy.
Some Progress Dynamics objects allow you to define a custom super procedure in the property sheet or other tool for creating objects of that type. For example, after you have created a set of browsers using the Object Generator, you can open each one that requires custom code by using the Open Object button in the AppBuilder. Or you can define a browser from scratch using the New button in the AppBuilder. Either way, you enter the AppBuilder’s property sheet for the browser, where you can name a custom super procedure, as you can see in Figure 1–1.
Custom super procedures can also be specified on the Save dialog box for objects in AppBuilder.
Remember that because the super procedure must be registered in the Progress Dynamics Repository like any other object, you do not need to specify the relative pathname of the procedure. This is stored as part of the definition of the procedure as a Repository object.
The AppBuilder allows you to set the custom super procedure for other objects you edit there, such as SmartDataViewers. Likewise, the Container Builder lets you define the custom super procedure for a dynamic window.
|
To use the Repository Maintenance tool to define a super procedure: |
- Run the Repository Maintenance tool from the Appbuilder Build menu.
- Enter the Object Name of the object and click Apply.
- Expand both the top-level node in the TreeView, the Objects node, the Attributes node under that, and click SuperProcedure.
- This brings you to the Attribute Value Maintenance window, where you can enter the name of the object’s custom super procedure in the Attribute value field, as shown:
Note that you can define custom super procedures in this way for both static and dynamic objects. If you want to associate extended behavior with multiple objects of a type (as an alternative to truly subclassing the type), you can simply add the super procedure to all the objects it should affect. Remember that if you want to add new attributes for the super procedure code to use, you must first add the attributes to the Repository (in the Attribute Maintenance tool), and then add them to the object type you are extending (in the Class Maintenance tool or in the Repository Maintenance tool).
And remember that a dynamic object is simply an instance of a single procedure, such as ry/obj/rydynviewv.w for dynamic viewers, that can read the right records out of the Repository to instantiate the object at run time. This one physical 4GL procedure serves all dynamic objects of the type. Thus there is always a procedure handle to associate with a super procedure, whether the object is dynamic or static. In the static case there is a separate source and compiled procedure for each object; in the dynamic case there is only one for all objects of a type.